Various ad hoc communication networks support packet communications in an asynchronous communication mode and/or a synchronous communication mode. The different communication modes may be used, for example, to support different services. For example, a synchronous communication link may be more appropriate for a demanding service, such as voice. One example of such an ad hoc network is a Bluetooth compliant network. The Bluetooth 1.1 standard (“BT-1.1”) specifies packets that include an access code, header and payload as illustrated in FIG. 1A. As will be more fully described below, the header is protected by a cyclical redundancy check (CRC) that is generally effective at detecting errors but not designed to correct errors. As one of the header fields may indicate a destination device for a packet, an indeterminate header error could lead to unintended reception by an incorrect device in the same Bluetooth piconet. As a result, the BT-1.1 standard specifies that a receiver discard any packets with errors detected by a bad CRC check on the packet header. This packet-handling approach is provided based on the requirements of a data-communications environment where the Bluetooth link is shared by multiple devices that may transmit bursts of data asynchronously. For such asynchronous communication mode operations, the destination of a packet is generally not known in advance to the receiver, which, therefore, operates to accept only its own packets.
Bluetooth also provides for support of various applications using a synchronous communication mode. For example, the BT-1.1 standard provides for supporting a real time application such as voice. In such a case, Bluetooth provides a synchronous link in which the transmissions are scheduled in advance to occur at regular intervals so that a receiver may know when to expect packets for the synchronous link. Dropped packets due to bad header CRC results may adversely affect voice quality in such a real-time application as with, for example, a Bluetooth headset.
The BT-1.1 standard will now be more fully described with reference to the baseband (BB) packet illustrated in FIG. 1A. As illustrated in FIG. 1A, the access code is 72 bits in length. The access code may be used by the receiver for timing recovery, frequency offset determination and compensation and/or channel access control functions. During normal link operations after a Bluetooth piconet has been established, a Channel Access Code (CAC) may be used to identify the particular piconet. Two other access codes, the Device Access Code (DAC) and the Inquiry Access Code (IAC) may be used during the piconet establishment procedures of paging and inquiry, respectively.
The header illustrated in FIG. 1A is 54 bits in length. The header may contain information for packet acknowledgement, packet sequence number for reordering, flow control, identity of the slave device within the Bluetooth piconet that is the intended destination or the source of the packet and/or the header error check (HEC), which is a type of cyclical redundancy check (CRC). As specified by the BT-1.1 standard, an 8-bit HEC is computed for a 10-bit header data field to form an 18-bit header. The 18-bit header may be protected by a rate-1/3 repeat code to form a 54-bit field as illustrated in FIG. 1A. The repeat code is specified for use in improving the signal to noise ratio at the receiver rather than for use in connection with an error correction code decoding processing at the receiver.
Also shown in FIG. 1A is the payload. The payload may be 0 bits for a null packet or range from 240 bits to 2,745 bits in length for data packets. The 240 bit length payload may be supported within a single time slot of the Bluetooth specified frame structure. Greater payload lengths may be supported by allocating multiple time slots within a frame for a single packet. The payload can contain data for either a synchronous connection-oriented (SCO) link or an asynchronous connection-less (ACL) link. Each payload type (ACL or SCO) may be provided a variety of different options for error correction, including no coding, rate 2/3 block and/or rate 1/3 sequential repeat code. The format of coding for the payload may be established at the time of negotiation of a link between a master and a slave device on a Bluetooth piconet.
Further details of the BT-1.1 standard format of the header are illustrated in FIG. 1B. As shown in FIG. 1B, the header includes a member address (AMER_ADDR) distinguishing between active members participating on a piconet, a packet type (TYPE), a flow control bit (FLOW) for flow control of packets over the asynchronous link, a one bit acknowledgement indication (ARQN) to acknowledge successful transfer of payload data, a sequence bit (SEQN) providing a sequential numbering scheme for ordering data in a packet stream and a header-error-check (HEC) to check the header integrity.